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NODE NETWORKING 


Donald R. Nelsch, K8EIW 
2545 N. Haven Blvd. 
Cuyahoga Falls, OH 44223 


ABSTRACT 


With the advent of NET/ROM (tm) Software 2000 Inc. and 
NORD<>LINK TheNet software, amateur packet radio networking 
became possible. However, some of the "factory standard" 
options in the software tend to limit performance of the 
system. This paper deals with someof the networking problems 
the author has resolved, plus someof the hardware 
considerations that were made in establishing and maintaining 
the authors' 21 transmitter interconnected node network. 


INTRODUCTION 


There were (and are) several "players" and prime movers 
in the N.E. Ohio Packet network, and certainly several 
interconnecting node operators who have joined us in what I 
believe to be the nations longest = "high-speed" (if you can 
consider 4800 baud as "high-speed"!), complex amateur radio 
packet network. The 4800 baud UHF backbone network as itis 
now configured, stretches from Cleveland on the north to 
Lexington KY (and perhaps beyond as you read this) onthe 
south with branches extending into Fremont in N.W. Ohio and to 
Cambridge in S.E. Ohio. In addition, there are many 
collocated tributaries on other bands which extend the range 
and function of the network to many other locations. 


HISTORY 


I first set up a single NET/ROM (tm) node in Cuyahoga 
Falls, OH in 1987 and with some grief, was able to "network" 
to a few distant nodes, but the results were not always the 
best. As myenthusiasm for packet radio increased, so did my 
investment in packet radio nodes in several locations in N.E. 
Ohio. Before long, I had in addition to the node in Cuyahoga 
Falls: (Akron -ID); node Sites “1n Mt. Gilead, “Cleveland, -Canton; 
Wayne County (Wooster) and most recently, Mansfield. It 
became apparent early on that we needed a better way to move 
traffic from city to city than on a heavily used 145.01 MHz. 
"keyboard" channel, so the idea of "back-boning" the data ona 
UHF "trunk" frequency was born, and implemented. Initially, 
our efforts on UHF were 1200 baud, but it soon became obvious 


that we needed something faster. The 4800 baud H.A.P.N. modem 
boards were available and seemed to work with the radios we 
had and so, an upgrade was planned. We determined very 
quickly that mixing speeds on one RF channel was an invitation 
to disaster in terms of interference primarily due to lack of 
proper data carrier detection between modulation types, so the 
conversion to 4800 baud on the UHF backbone was accelerated. 


Figure 1 shows the UHF portion of the Ohio Network as of July 
19905: 


HARDWARE SELECTION 


One of the early objectives in establishing the network 
was that any hardware needed to be uncomplicated, easy to 
replace, connectorized, and interchangeable! To accomplish 
this objective, I chose the Kenwood TM-221/321/421 series of 
radios as they were small, reasonably reliable, frequency 
agile (synthesized), and had the advantage of having fixed 
level audio available at the mike jack. This meant that we 
needed only one cable from the TNC to the radio, no pig-tails 
and no audio pots to tweak (and leave wrong!) The TNC chosen 
was the MFJ-1270b as it was the least cost TAPR-2 compatible 
TNC on the market. The TNC is very easy to convert for node 
operation. 


At this point, with very few exceptions, the K8EIW/WB8BII 
network is modularized to the point that one spare radio per 
band and one TNC and one power supply is all that is needed to 
effectively replace any of the 21 nodes should there "minor" 
flame-out at any of the sites. As one who has been involved 
with repeaters from the very early days, it is certainly a 
relief to not have to disconnect and reconnect 20 or more 
individual wires to replace a piece of equipment! 


NETWORKING PHILOSOPHY 


The network as I have configured it consists of three 
basic elements. 


1. User Ports. 
First, users need access to the network. By 
tradition, most amateurs have started out on 2 meters with 


their TNCs, so the logical choice for a "user" port is on 2 
meters. 
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2. High Usage Ports. 


Second, there are some high-volume users, such as 
Bulletin Board/message Systems (BBSs), and PacketCluster DX 
message systems. As their usage is quite high, they would be 
an unfair user of the available channel time compared with the 
individual users. We encouraged the BBSs to utilize 
frequencies in the 220 MHz band to enter the network for 
forwarding purposes. I am aware of 9 **Major** BBSs and DX 
PacketClusters in N.E. Ohio that are making good use of 220 
MHZ... Are. you: listening, «FC. C. 222 


3. Inter-Node Trunks. 


The third element, is the inter-node UHF backbone 
channel which is the main workhorse of the network. 


Into this mix, we need to stir frequency selection of 
both the user ports and the backbone ports. This also affects 
one other "little" concept of reliability/redundancy vs. the 
problem of frequency congestion. 


In N.E. Ohio, propagation and terrain is such that with a 
6 element beam antenna on a 25 watt radio on UHF, we can 
expect a solid path between the node sites which are between 
20 and 45 miles apart, and a useable path most of the time 
over a 45 to 70 mile path, which is about the distance between 
two non-adjacent nodes. For purposes of redundancy, I have 
chosen to put all UHF nodes on the same frequency, and by 
proper selection of the p-persistance parameter, have managed 
to get the nodes to "live" together very well. I have found 
that data transfer is greatly enhanced if a backbone node 
"talks" only to the immediate adjacent node in serial fashion 
as opposed to hopping over adjacent nodes. To.-aad. co the 
complexity of this situation, at mostsites,I have a 220 MHz 
node and a 2 meter node that can also **talk** to the adjacent 
or perhaps the second adjacent node site. It is here that 
proper selection of node parameters becomes very important to 
the smooth operation of the network. 


ROUTE QUALITY V8 NODE QUALITY 


Distant nodes often tend to comeand go with propagation 
(and other reasons!), but an adjacent node, hence the ROUTE to 
that adjacent node tends to remain reasonably stable. If 
NODES are locked in the data base, 1t 1S not uncommon for 
routing loops to be established when propagation changes, and 
for whatever reason to not be unlooped when things get back to 
"normal". It is for this reason that I have chosen to lock 


the ROUTE values to known good nodes to a predetermined high 
value and to default itinerant nodes to some low value such 
that they will show up in a node and/or route list but not 
propagate through the network as a first choice route. This 
Saves routing loops and at the same tme, also givesthe users 
some idea of what the band conditions may be (is it "up" or 
"GOwn 2 )is Also, by proper selection of ROUTE values, the 
desired path value from any node in the network to any other 
node (user, high usage or backbone) may be preselected 
numerically, and will change dynamically as nodes or 
propagation changes without any human intervention. This 
means that if an intermediate node is "lost" due to a failure, 
the routing algorithm in the nodes will cause the routing to 
try the second choice route, which maybe either to "hop" the 
Silent node or possibly to use an alternate frequency to get 
tothe adjacent site. 


The point of this exercise is that the node operator's 
first objective should be to get the data through on the 
primary route. Should the primary route fail, the second 
choice route should be a viable path, and if that has also 
failed, the third choice route is the last hope! MThis all 
needs to be done dynamically by the TNC processor and WITHOUT 
operator intervention. Proper ROUTE quality selection 
achieves this objective. 


ROUTE QUALITY NUMBERS 


One of the concepts that needs to be understood by node 
sysops is the concept of route quality. Basically put, there 
is an arbitrary "quality" value put on the path between two 
nodes by the node operator. The quality of a destination node 
in the originating node list is determined by an algorithm in 
the firmware based on the route quality. This number is 
calculated on receipt of each nodes broadcast. The networking 
routines will select the three best paths to be used in an 
attempt to establish an end-to-end connection. While the node 
operators can directly change the path quality to a specific 
node, it is usually best left to the algorithm to avoid path 
looping situations. 


One of the objectives is to keep all inter-node traffic 
off the "user" or keyboard channels. By proper assignment of 
route qualities for adjacent and non-adjacent nodes, we can 
then determine what the path quality to the node will be, 
hence, its position on the path list. We can literally force 
the system to chose an indirect route from one node to another 
as opposed to a direct route by assigning higher values for 
the indirect "backbone" routes. In fact, this is what has 
been done in our network. A 2 meter node will actually chose 
to connect to an adjacent co-channel 2 meter node via the 
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backbone route, thereby relieving inter-node traffic 
congestion on the primary **keyboard** channel. Should there be 
a failure of the UHF links, the path guality algorithm can 
then permit a direct 2 meter connection, thereby providing 
redundancy of path. Likewise, if an adjacent backbone node 
site is completely disabled, the long-haul logical path can be 
maintained on the UHF backbone frequency from the first node 
to the non-adjacent node prior to the two meter path being 

Yea lazed:. To add complication to the maze, in at least three 
locations, we have a 220 MHz frequency in use as well. Once 
again, by proper selection of route qualities, we can force 
inter=node trative To: wse firs: the. UAF channel, then the: 220 
MHz channel, then as third and final choice, the 2 meter path, 
or perhaps a slightly more round-about path on UHF. 


Figure 2 displays the model that I have developed for use in 
establishing Route Quality Numbers. 


One evident fact is that all node operators need to have 
similar philosophies about "DX" nodes, otherwise convoluted 
unworkable paths WILL be set up during band openings. 


OTHER CONSIDERATIONS 


When establishing values for the parameter list, several 
things need to be considered. FIrst,. nd “to. end connections 
over 3 hops seem to fail when there are more than about 70 
nodes in the list. I am sure that the mathematicians in the 
group can define what that break-point is, but my experience 
says that anything over about 70 nodes in the list invites 
disaster. This is especially true if the user attempts the 
connect using the alias as opposed to the call-sign. Tr. Che 
node list is hard-limited by the parameter list to limit the 
number to 70, a desired, working, in-use node path could "fall 
out" of the list when another node broadcast was heard and the 
list overflowed the in-use node out! Therefore, other means 
of limiting the number of nodes in the list needs to be made. 
I have chosen the minimum node quality parameter such that a 
full-time desired node will have a node propagation distance 
of approximately six hops. This is usually sufficient for 
most BBS and TCP/IP purposes. Intermittent nodes, ones that 
are present only during band openings, will NOT propagate past 


the anitial node stack. This is done by selection of the 
default node quality (Parameter 3) to be 1 more than Ene 
minimum acceptable quality (Parameter 2). Parameter 2 1s set 


sufficiently high so that desired nodes will appear but the 
number of "normal" nodes will not exceed the approximately 70 


number. 


There might be a case where a node is a "desired" 
destination due to its network function, such as aTCP/IP mail 
server for the region, and is more than six node hops from the 
most distant entry point to the network. In those cases, the 
node operator certainly has the option of locking that 
specific node path value to an artificially high value. In 
N.E. Ohio, I generally choose the adjacent node to "boost" the 
path quality of the "desired" node to a very high value. 
However, should the "desired" node be down for ANY reason, 
network routing loops will be set up and the "desired" node 
can expect several hours of no traffic upon its return until 
the entire network learns of its recovery and/or a sysop 
intervenes. 


As can be plainly seen, path quality determination can be 
an extremely complex issue and becomes even more so as more 
nodes are established by more groups. It is certainly not an 
easy issue when all of the nodes are under one-person control, 
and seven more complex when there are as many node operators 
as there are nodes! What is needed is a generalized 
"standardized" list of parameters for use in a populated 
network. Perhaps the original “factory standard defaults" 
were a place to start, but they are absolutely unsatisfactory 
in todays' environment. Other factors which play an important 
part in a well-functioning network include p-persistence, time 
to live, maximum node list, number and frequency of node 
broadcasts, maximum congestion thresholds, and the list goes 
on. 


Suffice to say, the main objective is to pass the traffic 
presented in a timely manner with the minimum of congestion 
created internal to the network. If the nodes are able to 
communicate with each other on a non-interfering basis during 
any type of propagation conditions, then we have basically 
achieved the objective. 


It is therefore with a mixture of pleasure and hesitancy 
that I am suggesting the following list of parameters in 
Figure 3 as a better place to start than the **factory 
Standard? The hesitancy is knowing that there will be places 
and conditions that will need different "numbers", I present 
them as what works in N.E. Ohio with our terrain and 
propagation conditions, and your conditions may vary "from 
state to state, local laws prevailing? 
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SITE A SITE B SITE C 


USER CHAN <——————— 192 ————— USER CHAN <—————— 192 -—~~-—-~--> USER CHAN 
(145.01 MHz.) 


f 140 (Or Default Parm 3) } 


ALT USR CHAN <—-—— 192 -~----—-—> ALT USR CHAN <-—--—-—-—-~- 192 -——-——> ALT USR CHAN 
(221.11 MHz.) 


t 140 (Or Default Parm 3) f 


HIGH USE CHAN <——--——— 224 
(223.7 MHz.) 


t 200 first choice (A -> C)f 
t 194 second choice (A -> B -- C) f 


> HIGH USE CHAN <—-—-—~— 224 -—-—--> HIGH USE CHAN 


BACKBONE <—----——— 225 --------> BACKBONE e---p-- 225 
(446.5 MHz.) 
t 205 first choice (A ~~ C)f 
t 195 second choice (A -- B -> C) t 


----> BACKBONE 


PATH QUALITIES 
(Within Node Stack) 


(1 <- 2) = 246 (3 <- 1) = 240 

(1 <- 3) = 247 (3 <- 2) = 248 

(1 <- 4) = 248 (3 <- 4) = 248 

(2 <- 1) = 246 (4 <- 1) = 248 

(2 <- 3) = 247 (4 <- 2) = 248 

(2 <- 4) = 248 (4 <- 3) = 248 
e.g. at [1], R 1 (2) +246 at [4], R 1 [1] +248 
R 1 [(3] +247 R 1 [2] +248 
R 1 [(4] +248 R 1 [3] +248 


FIGURE 2. 
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Description Value Comments 

Max. Dest. List 100 See Text. 

Worst quality for updates 129 Set so that NodeList < 70 

Channel O default 130 See Text. 

Channel 1 (RS-232) Quality 248 See Text. 

Obsolescence Counter 6 

Obs. Count. Min. 4 Insures Bdcast is not "trashed" lst Time 
Auto Update Interval 1800 1/2 hr Helps Keep List "Fresh" 

Time to live 15 More reasonable! 

Transport Time Out (sec.) 120 Give it a chance! 

Transport Max. Tries 5 Give it a chance during busy periods! 
Transport Ack Delay (sec) 10 

Transport Busy Delay (sec.) 180 


Transport Window Size 
Congestion Control (frames) 


(frames) 4 


Don't £ill the INC buffers! 


No Activity Time Out 900 Set MUCH Higher for DX PktClstr Access Chan. 
P-persistance 50 Max for Backbone - 64 OK for User Channel 
Keyup Slot time 10 

Link T1 "Frack" (sec) 4 

"MAXFRAME" 7 Some Opinions say MAXFRAME = 1! 

Link Max tries 7 Enough is Enough! 

Link T2 timeout 100 

Link T3 Timeout 18000 

AX.25 digipeating 0 NOT ON BACKBONE! = OK on User Channel. 
Validate Callsigns 1 Keep ’em Honest! 

Station ID beacons 1 Keeps the MSYS/KANODE JHeard lists happy. 
CQO broadcasts 0 NOT ON BACKBONE! = OK on User Channel. 


= 500 ms on ALL Synthesized Radios = It takes TIME for TX AND RX PLL’sS to Lock! 


SUGGESTED PARAMETER VALUES 
FIGURE 3 


